To be consistent with existing concepts like the srcRefs property, I'd suggest to rename this field to identitySelector and only allow a flat mapping of identity relevant properties, e.g.:

identitySelector:
  name: my-image
  version: 1.2.3
  architecture: amd64

The label name names the semantical convention we want to define as part of the ocm spec. It should not be odg specific and should contain the convention name. The version should be moved to the version field. The values then should focus on the actual reference logic. My idea:

Is the metadata really needed? If the type of the resource which has the label is sbom, isn't that already descriptive enough?

The label name names the semantical convention we want to define as part of the ocm spec.

Looking at the spec, shouldn't the label name then rather just be artefactReference?

The version should be moved to the version field.

+1

Is the metadata really needed?

I agree that we probably don't require the current metadata property. However, as also discussed in the hackathon, we will need some sort of mechanism to further specify the kind of reference (e.g. in case there are multiple SBOMs for the same artefact). I would suggest to use the extraIdentity field of the referencing artefact (here: the OCM resource for the SBoM) for this, e.g.:

resources:
  - name: my-image
    version: 1.2.3
    type: ociImage
    extraIdentity:
      foo: bar
  - name: my-image-sbom
    version: 1.2.3
    type: sbom
    extraIdentity:
      architecture: amd64
    labels:
      - name: artefactReference
        version: v1
        value:
          identitySelector:
            name: my-image
            version: 1.2.3
            foo: bar
  - name: my-image-sbom
    version: 1.2.3
    type: sbom
    extraIdentity:
      architecture: arm64
    labels:
      - name: artefactReference
        version: v1
        value:
          identitySelector:
            name: my-image
            version: 1.2.3
            foo: bar  

Wdyt about this approach?

@8R0WNI3 I think that's really good

Just asking myself: if someone puts name and version into extraIdentity, what happens?
But having something like identitySelector.extra feels too nested :/

If someone puts name and version into extraIdentity, what happens?

According to the spec, the name may not be part of the extra identity. If the version is part of the extra identity, this does not matter (I think). To my knowledge, the component descriptors of Gardener even write the version explicitly into the extra identity, thus making the implicit contract defined in the spec explicit.

But having something like identitySelector.extra feels too nested.

I agree. Also, flattening the extra identity matches the behaviour implemented by the already existing srcRefs property.

The resource type should be sbom, see

The media type of the resource access should be spdx+json

I would suggest to just name it ocm.software/artefact-ref

The linking will be part of OCM core, used by other tooling and not only ODG

There is also a dedicated version property for OCM labels, see: https://github.com/open-component-model/ocm-spec/blob/main/doc/01-model/03-elements-sub.md#labels

From my understanding type would be sbom, and application/spdx+json would become the file's mediaType

See: https://ocm.software/docs/reference/input-and-access-types/#filev1